1. Field of the Invention
The present invention relates to Hypertext Transfer Protocol (HTTP) sessions, and particularly relates to a method and system for separating HTTP sessions.
2. Description of Related Art
An HTTP protocol is a unilateral protocol. According to the HTTP protocol, a server can not initiate a connection to a client, but passively waits for and responds to a request from the client. Since the HTTP per se does not support storing state information of the client in the server, a state management mechanism, i.e. a session mechanism, is introduced to maintain state between the server and the client.
The introduction of session mechanism overcomes some limitations of HTTP, so the relationship between requests can be maintained at the client and the server. Based on the session mechanism, when the client first connects to the server, a HTTP session is established at the server where session-related variables are stored, and meanwhile a HTTP session identifier (ID) is generated to identify the variables of the session. Next, the server instructs a browser to generate a “Cookie” corresponding to the HTTP session. A Cookie is a small segment of text stored in the client by the server. During the session, each time a HTTP request is sent to the server through the browser, the session identifier contained in the Cookie is included in the HTTP request and further sent to the server, so the server can identify the session and obtain the session related variables.
However, typically in the prior art, a plurality of service instances corresponding to the same application may be required to run in a HTTP session. Under this circumstance, the plurality of service instances share the same HTTP session. At this point, a problem will arise.
FIG. 1 shows an example of an environment where a problem likely arises in the prior art. As shown in the figure, there are two servers in the example, one being a portal server 110, the other being a SaaS (Software as a Service) server such as an accounting application server 120.
A user may log in the portal network server 110 with his own user ID and password through a browser, and then enter page 100. The page 100 includes three user interface components, IFrame 101, IFrame 102 and IFrame 103. Since all of IFrame 101, IFrame 102 and IFrame 103 correspond to the same accounting application, their access points are identical. However, a service instance corresponding to IFrame 101 is main data of “A” company, a service instance corresponding to IFrame 102 is main data of “B” company, and a service instance corresponding to IFrame 103 is main data corresponding to “C” company.
The bottom left of FIG. 1, shows an example of Cookie 104 when the three IFrames are all opened. From the example it is seen that the Cookie 104 has two session IDs, i.e. JSESSIONID 105 and JSESSIONID 106. JSESSIONID 105 is in use when communicating with the portal server 110, and at the same time, variable information 111 corresponding to JSESSIONID 105 is saved in the portal server 110. JSESSIONID 106 is in use when communicating with the portal server 120, and at the same time, variable information 121 corresponding to JSESSIONID 106 is saved in the portal server 121.
According to the prior art, in this scenario there are three service instances corresponding to the accounting application, all of them using JSESSIONID 106 when communicating with the accounting application server 120. Since it is unable to distinguish which service instance is in use by means of the JSESSIONID 106, a problem arises. This is because, after the main data of “A” company is operated, the session variable stored at the accounting application server 120 is a value associated with “A” company, while after the main data of “B” company is operated, the session variable stored at the accounting application server 120 may be associated with “B” company. Thus, after the main data of “B” company is operated, what is shown when returning to look up the main data of “A” company may possibly be the main data associated with “B” company, which causes great confusion and may further result in data error.
In some applications, a mechanism is specially designed to avoid such problem by forbidding the operation when a plurality of service instances are detected trying to require instantiating a same application during the same HTTP session. In other words, if one wants to handle data of another company, the current HTTP session has to be closed so as to re-connect to the server. Though problems of data confusion and data error are avoided by this solution, it is very bothersome and not user-friendly. Thus, this solution can not fundamentally satisfy business needs.
There is another solution that only guarantees the correctness of the data of the service instance which is latest accessed. This solution is simple, but the user can not look up main data of previous application instances, which still brings great inconvenience to users.
Though FIG. 1 shows an environment in which the accounting application server and the portal server are located in the same domain, in fact, these problems also exist in an environment that the accounting application server and the portal server are in different domains.